|
|
|
|
|
|
|
quickly produce a list of global or form-level functions that seem to roughly provide the expected system behavior; analysis is over in a heartbeat. Analysis is really design, if that. It becomes quite tempting to grab some programming tips-and-tricks books and start forcing this analysis and design model of functions to incorporate ideas of how the system should work. This is a common concern and is known as fly-by-the-seat-of-your-pants development, or programming by chaos. |
|
|
|
|
|
|
|
|
Quoting noted object-oriented methodologist Jim Rumbaugh, analysis is the careful examination of the requirements for a system with the intent of understanding them, exploring their implications, and removing inconsistencies and omissions. Effective analysis builds on the mature (or evolved) requirements model by evolving an ideal structure that endures throughout the life cycle of the proposed system under development. During the early iterations of your analysis processes, you don't want to formulate a detailed list of low-level functions to rush out the door without concern for how the user uses the system and how the system responds to those uses. By low-level, I mean that you don't want to worry about which database you're using, which neat trick you want to incorporate to make a MAPI or Windows API call, or similar notions. This is important because changes in vendors, for instance, can necessitate a change in tools or even operating systems. Also, by avoiding the detailed design stuff early in the analysis iteration, you can better concentrate on the activities of the business process user because the analysis model is far simpler than the design model(s). |
|
|
|
|
|
|
|
|
A mature design model provides direct guidance to your programming activities, whereas an analysis model provides a solid foundation for your design model(s). Figure 2.2 gives you an example of a simple analysis model. Note how it's focused only on high-level business objects when initially created. In the User Services layer of the proposed system, a Teller Interface class encapsulates your understanding of the interaction between the user and the system. Don't worry about button clicks or mouse movements. Also, a Checking Account class and a Savings Account class encapsulate your knowledge of each type of account. You could easily have one class called Account at this stage; it depends on your particular environment. Finally, there's a Persistence class, which is responsible for storing and retrieving information created or modified in your application, as well as eliminating information the user wants destroyed. In the analysis model, it's called persistence, as opposed to database management, because you don't know whether the data repository will be a database or a flat file (regular text or a binary file you store anywhere on your hard disk). That kind of detail is left to your design model. |
|
|
|
|
|
|
|
|
The role of the architect is to formulate and facilitate the elaboration of the system's architectural foundation. The advantage of understanding this role is that you're able to |
|
|
|
|
|